(19) 



J) 




EuropaisSTTes Patentamt 
European Patent Office 
Office europeen des brevets 



III 



(12) 



(43) Date of publication: 

02.01.2004 Bulletin 2004/01 

(21) Application number: 03101738.7 

(22) Date of filing: 13.06.2003 



(H) EP 1 376 353 A2 

EUROPEAN PATENT APPLICATION 

(51) lntCl7: G06F 9/50 



(84) Designated Contracting States: 


(72) Inventor: LEHTINEN, Pekka 


AT BE BG CH CY CZ DE DK EE ES Fl FR GB GR 


04440, Jarvenpaa (Fl) 


HU IE IT LI LU MC NL PT RO SE SI SK TR 




Designated Extension States: 


(74) Representative: Pursiainen, Timo Pekka 


AL LT LV MK 


Tampereen Patenttitoimisto Oy, 




Hermiankatu 12B 


(30) Priority: 20.06.2002 Fl 20021204 


33720 Tampere (Fl) 


(71) Applicant: Nokia Corporation 




00045 Espoo (Fl) 





CM 

< 

CO 
lO 
CO 

CD 
CO 



CL 
LU 



(54) Method and system for executing applications sessions in an electronic device 



(57) The current invention relates to a system com- 
prising means (2, 4) for scheduling the execution of ap- 
plication sessions and the necessary resource reserva- 
tions in an electronic device (1) with one or more proc- 
essors (2). The system comprises means (2) for sched- 
uling the resource reservations and the execution of ap- 
plication sessions that are to be executed substantially 
simultaneously. The application session to be executed 
is composed of one or more Activity Blocks (AB) that 
are located in one or more Activity Block Containers 
(ABC, ABC1 , ABC2, ABC3), and an execution order of 
these Activity Blocks is pre-defined for said Activity 
blocks (AB). The system comprises resource type spe- 
cific Resource Handlers (RH) for the reservation of re- 
sources f or the application session, Resource Allocation 
Manager (RAM, RAT, RH, RIT) for the bookkeeping and 



analysis of the resource allocation situation, Application 
Session Management and Scheduling means (ASM) for 
selecting the next application session and Activity Block 
at least on the basis of said resource allocation situation, 
executing means (2, ASM) for executing the Activity 
Block (AB) in the course of the selected application ses- 
sion. The system is provided with a protocol (SCP) con- 
necting said Resource Handlers (RH), Resource Allo- 
cation Manager, Application Session Management and 
Scheduling means, and executing means to control the 
execution order and to implement the transfer of infor- 
mation between said resource reservation means, Re- 
source Allocation Manager, Application Session Man- 
agement and Scheduling means, and executing means. 
The invention also relates to a method for the execution 
of application sessions in an electronic device (1 ), as 
well as to an electronic device (1). 
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Description 

[0001] The current invention relates to a system com- 
prising means for executing application sessions in an 
electronic device equipped with one or more processors s 
and means for scheduling resource reservations and 
the execution of substantially simultaneous application 
sessions. The invention also relates to a method for ex- 
ecuting application sessions in an electronic device in 
which the operation is controlled by one or more proc- 
essors, with resource reservations and the execution of 
substantially simultaneous application sessions being 
scheduled in this method. Furthermore, the invention re- 
lates to an electronic device comprising means for exe- 
cuting application sessions, one or more processors, 
and means for scheduling resource reservations as well 
as the processing of substantially simultaneous appli- 
cation sessions. Furthermore, the invention relates to a 
software program comprising machine executable 
steps for executing application sessions in an electronic 
device with one or more processors for synchronizing 
Resource Reservation Instances as well as the execu- 
tion of substantially simultaneous application sessions 
[0002] As the capabilities of wireless communication 
devices get more and more rich, there is a need to de- 
velop systems for utilizing these capabilities in a sensi- 
ble and versatile way. In modern wireless communica- 
tion devices, it is even possible to execute several ap- 
plication sessions with different objectives, such as a 
calendar, a timer, a telephone directory, a notepad, etc. 
It may often be necessary to run several such sessions 
substantially simultaneously, wherein problems may oc- 
cur, for example, when different sessions would require 
the same resources of the wireless communication de- 
vice itself or resources available via various connec- 
tions, at the same time. For example, there are operat- 
ing systems which are intended for data processing de- 
vices, such as UNIX®, implementing a multi-task meth- 
od, i.e. the processing of several Operating System 
tasks substantially simultaneously. Such a multi-task 
method is implemented, for example, in such a way that 
each session is implemented in the form of a single soft- 
ware process and the operating system allocates 
processing time to each process in a given order. Thus, 
during the execution of one session, the other sessions 
are in a suspension state. Consequently, in practice, the 
sessions are not executed simultaneously but one after 
the other. However, the processing time allocated to 
each session at a time is so short that there is a feeling 
of all the sessions being executed simultaneously. In 
such an arrangement, none of the sessions normally 
needs to wait for so a long time that the execution of the 
session would seem to be interrupted. However, in a sit- 
uation in which the number of sessions executed simul- 
taneously is increased, less and less processor time is 
left for each session, which will slow down the execution 
of all the sessions. In some systems, it is possible to 
classify the sessions in accordance with their impor- 



tance (prioritisation), 

wherein the sessions are allocated processor time ac- 
cording to their priorities. In this arrangement, the exe- 
cution of less important sessions may be significantly 
delayed. 

[0003] Multi-task systems of prior art have also incor- 
porated the problem that if any session requires a hard- 
ware resource and/or an operating system resource, 
this session will reserve the resource for as long a time 
as is required for the use of the resource. Thus, other 
sessions that would need the same resource must wait 
for the release of this resource, because there is nor- 
mally no such method by which the resource could be 
transferred from one session to another in such a way 
that this resource availability situation would be known 
to each session involved. For such situations, some so- 
lutions have been developed, in which the operating 
system uses semaphores, or the like, to prevent the use 
of a reserved resource from other sessions requesting 
the same resource. 

[0004] The execution of several application sessions 
in wireless communication devices should be as close 
to real time operation as possible, for example, in view 
of the convenience of using a wireless device. For ex- 
ample, when initiating a call, a telephone directory ses- 
sion should be executed as quickly as possible so that 
the user of the wireless communication device would 
find the required telephone number without an undesir- 
able delay. However, this kind of real-time operation 
may be difficult to implement, particularly when there is 
a large number of sessions to be executed simultane- 
ously in the wireless communication device. One known 
solution to meet the demands of multi-task and real time 
processing is to make use of several processors in the 
same device. Thus, different sessions can be executed 
by different processors. However, this involves e.g. the 
drawback that when the number of processors is in- 
creased, the power consumption of the device is also 
increased, which should be avoided particularly in port- 
able devices. Furthermore, in systems with several 
processors, arrangements are needed, whereby differ- 
ent application sessions are allocated to be executed by 
different processors. 

[0005] For embedded applications, multi-task sys- 
tems have been developed, in which the execution of 
different sessions can be scheduled, and each session 
can be allocated processing time when necessary. How- 
ever, such embedded applications are designed for spe- 
cific purposes only, wherein it is largely possible to de- 
termine in advance, which sessions are to be executed 
under different conditions and which resources will be 
needed at each time. In this case, the scheduling of the 
sessions can be determined in advance. In addition, 
these applications do not include an operating system. 
Such multi-task systems are not suitable for use in wire- 
less communication devices, in which it is not possible 
to determine, in advance, all the different use cases and 
the related resource needs. 
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[0006] Considerable problems in multi-task systems 
include the management and scheduling of resource 
reservations as well as the management and scheduling 
of application sessions, in other words, the synchroni- 
zation of the allocation of the processor and other types 
of resources, to meet the demands of different sessions. 
However, these problems cannot be solved separately, 
wherein it is difficult to find suitable solutions for both 
problems. 

[0007] One objective of the current invention is to pro- 
vide an improved arrangement particularly for wireless 
communication devices to implement a multi-task sys- 
tem which operates as close to real time as possible. 
The invention is based on the idea of specifying a ses- 
sion execution environment that includes different func- 
tional blocks for controlling the execution of application 
sessions and the reservation of resources. A central one 
among these functional blocks is the management of 
application sessions and resources, that is divided into 
e.g. an application session management and schedul- 
ing block (also called as Application Session Manager, 
ASM) and a resource management and allocation block 
(also called as Resource Allocation Manager, RAM). 
The application session to be executed is divided into 
successive and parallel activities which are implement- 
ed in the form of corresponding application blocks, 
which in this description of the current invention are 
called as activity blocks. The application session man- 
ager ASM is responsible for the scheduling (e.g. initiat- 
ing) of the activities of each session one by one, e.g. on 
the basis of the resources available. The Resource Al- 
location Manager RAM is responsible for all the central- 
ized management and synchronization functions relat- 
ed to the different resource types and resources, for ex- 
ample, by keeping a record of individual resource res- 
ervations and informing the Application Session Man- 
ager accordingly. An essential feature in the operation 
of the system according to the current invention is the 
relative scheduling of the Application Session Manager 
and the Resource Allocation Manager, that is imple- 
mented in such a way that substantially immediately af- 
ter each execution turn of the Resource Allocation Man- 
ager, when the resource allocation situation of at least 
some resources is stable (i.e. as up-to-date as possi- 
ble), actions of the Application Session Manager are ex- 
ecuted. Other Functional Blocks of the system include, 
for example, Resource Handlers RH for each resource 
type, as well as Activity Block Containers ABC. The Re- 
source Handlers maintain so called Resource Instance 
Records RIR of individual allocations of the respective 
resource types in their Resource Instance Tables RIT. 
Each Activity Block Container preferably contains such 
Activity Blocks of one or more sessions, that are nor- 
mally executed successively without a need for parallel 
processing. The Resource Handlers can be ideally im- 
plemented as software processes which have priorities 
on a higher level than the Resource Allocation Manager, 
wherein the Resource Allocation Manager receives the 



processor from the Operating System in a situation 
when the Resource Handlers have processed both their 
application- and resource-originated messages, and the 
resource allocation situation is temporarily unambigu- 
5 ously known, at least concerning some resources. An- 
other functional characteristic of the invention is a Ses- 
sion Control Protocol SCP that is applied e.g. for the 
transmission of messages between different parts of the 
system (i.e. members of an application session). 
w [0008] To put it more precisely, the system of the cur- 
rent invention can be primarily characterized in that the 
application session to be executed comprises one or 
more Activity Blocks in one or more Activity Block Con- 
tainers, and an execution order is specified for said Ac- 
's tivity Blocks; that the system comprises resource type 
specific Resource Handlers for reserving resources for 
the application session, Resource Allocation Manager 
for analysing and saving the resource allocation situa- 
tion, Application Session Management and Scheduling 
20 means for selecting at least the next application session 
and Activity Block to be executed on the basis of said 
resource allocation situation, executing means for exe- 
cuting the next Activity Block in the course of the select- 
ed application session, and the system is provided with 
25 a protocol connecting the Resource Handlers, Re- 
source Allocation Manager, Application Session Man- 
agement and Scheduling means and executing means, 
to control the execution order and to implement the 
transfer of information between said Resource Han- 
30 dlers, Resource Allocation Manager, Application Ses- 
sion Management and Scheduling means, and execut- 
ing means. 

[0009] The method of the current invention can be pri- 
marily characterized by that the application session to 
35 be executed comprises one or more Activity Blocks in 
one or more Activity Block Containers, and the execu- 
tion order is determined for said Activity Blocks; that the 
method comprises at least the following steps: 

40 - a resource management and allocation step for re- 
questing and reserving resources to the application 
session, 

a bookkeeping and analysis step for saving and an- 
alysing the resource reservation situation, 
45 - a scheduling and selection step for selecting the 
next application session and Activity Block to be ex- 
ecuted at least on the basis of said resource reser- 
vation situation, 

an execution step for executing the next Activity 
50 Block in the course of the selected application ses- 
sion, 

wherein in the method, a communication protocol con- 
necting said resource management and allocation step, 
55 bookkeeping and analysis step, scheduling and selec- 
tion step, and the execution step is used to control the 
execution order and, if necessary, to transfer informa- 
tion between said resource management and allocation 
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step, bookkeeping and analysis step, scheduling and 
selection step, and execution step. 
[0010] Furthermore, the electronic device of the cur- 
rent invention can be primarily characterized in that the 
application session to be executed comprises one or 5 
more Activity Blocks in one or more Activity Block Con- 
tainers, and an execution order is determined for said 
Activity Blocks; that the electronic device comprises re- 
source type specific Resource Handlers for reserving 
resources for the application session, Resource Alloca- 
tion Manager for analysing and saving a resource allo- 
cation situation, Application Session Management and 
Scheduling means for selecting at least the next appli- 
cation session and Activity Block to be executed on the 
basis of said resource allocation situation, executing 
means for executing the next Activity Block in the course 
of the selected application session; and the electronic 
device is provided with a protocol connecting the Re- 
source Handlers, Resource Allocation Manager, Appli- 
cation Session Management and Scheduling means 
and executing means, to control the execution order and 
to implement the transfer of information between said 
Resource Handlers, Resource Allocation Manager, Ap- 
plication Session Management and Scheduling means, 
and executing means. 

[001 1 ] The software program of the current invention 
can be primarily characterized in that the application 
session to be executed comprises one or more Activity 
Blocks in one or more Activity Block Containers, and an 
execution order is determined for said Activity Blocks, 
that the software program further comprises machine 
executable steps for performing at least the following 
steps: 

a resource management and allocation step for re- 
questing and reserving resources for the applica- 
tion session, 

a bookkeeping and analysis step for saving and an- 
alysing the resource reservation situation, 
a scheduling and selection step for selecting the 
next application session and Activity Block to be ex- 
ecuted at least on the basis of said resource reser- 
vation situation, 

an execution step for executing the next Activity 
Block in the course of the selected application ses- 
sion, 

wherein in the software program comprises machine ex- 
ecutable steps for using a communication protocol con- 
necting said resource management and allocation step, 
bookkeeping and analysis step, scheduling and selec- 
tion step, and the execution step to control the execution 
order and, if necessary, to transfer information between 
said resource management and allocation step, book- 
keeping and analysis step, scheduling and selection 
step, and execution step. 

[0012] The current invention shows remarkable ad- 
vantages over solution methods of prior art. By the 



method of the invention, one session does not neces- 
sarily reserve a resource facility entirely for itself and not 
necessarily for the entire duration of the session, where- 
in it is possible to allocate resources substantially simul- 
taneously (i.e. in parallel) to more than one session and 
also to synchronize the reservation times of the simul- 
taneously required resources of each session as opti- 
mally as possible. The utilization of the resources and 
the processor during the execution of the sessions can 
be efficiently implemented in the system of the inven- 
tion, assuming that the Application Session Manager is 
furnished with the sufficient control intelligence for 
scheduling. By the method of the invention, it is possible 
to manage overload conditions and to avoid the occur- 
rence of deadlocks. During overload conditions, it is 
possible to suspend ongoing application sessions in ac- 
cordance with their priorities, and to delay the initiation 
of new application sessions. This applies to overload 
conditions of other shared resources as well, and not 
only processor overload conditions. According to the in- 
vention, the Session Control Protocol SCP and the pri- 
oritisation rule of the software processes (OS tasks) of 
different functions enable the scheduling and synchro- 
nization control of the operations involved in an applica- 
tion session even in processor overload conditions, 
wherein several software processes (OS tasks) may 
have several unhandled messages at the same time. 
The order of processing messages which are unhandled 
at the same time is determined according to the priori- 
tisation principle of the software processes (OS tasks) 
participating in the application session in accordance 
with the normal task switching mode of the Operating 
System. Furthermore, the arrangement of the invention 
has the advantage that the power consumption of a 
Wireless Communication Device can be reduced in sit- 
uations in which the load level is so low that the proces- 
sor can operate with a reduced power level. The Appli- 
cation Session Manager ASM enables the detection of 
load conditions that are different from the viewpoint of 
the power consumption for control purposes. The soft- 
ware architecture of the invention offers a solid software 
environment, 

wherein the design of each Activity Block for the Wire- 
less Communication Device is as uniform as possible, 
independently of the individual activity involved and the 
complexity of the related application session. Further- 
more, the structuring of each application session into 
Activity Blocks makes it possible that the software de- 
velopment work needed for implementing the applica- 
tion can be easily realized by dividing the application 
session into separate activities, each one in the form of 
an Activity Block. The Application Framework offered by 
the Activity Block Containers can be designed to include 
the sending and reception of the generic SCP messages 
of all the parallel application sessions without a need for 
the application designer to be aware of the presence of 
the Session Control Protocol, the Application Session 
Manager, or the Resource Allocation Manager. In soft- 
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ware development based on the Activity Blocks of the 
software architecture of the invention, it is possible to 
utilize powerful software development tools and to effi- 
ciently re-use both the Activity Blocks and the SCP- 
based behavioural pattern integrating these blocks in 
accordance with an Application Session Profile. In the 
architecture of the invention, the Application Session 
Manager is responsible for the initiation of the execution 
of each Activity Block at an appropriate time. 
[001 3] In the following, the invention will be described 
in more detail with references to the appended draw- 
ings, in which 

Fig. 1 shows a Wireless Communication Device cor- 
responding to a preferred embodiment of the 
invention in the form of a simplified block dia- 
gram, 

Fig. 2 outlines a system corresponding to a preferred 
embodi ment of the invention, 

Fig. 3 outlines the functional structure of an Activity 
Block Container implemented in a system cor- 
responding to a preferable embodiment of the 
invention, and 

Fig. 4 shows the utilization of the method of the in- 
vention in the case of an application session 
example. 

[001 4] In the following, the invention will be described 
in such respects that the functions needed for imple- 
menting the invention will be disclosed. However, even 
though the various functionality of the system will be de- 
scribed in the following in a blockwise manner, it is ob- 
vious that several Functional Blocks co-operate to carry 
out several different functions by means of the Session 
Control Protocol. 

[001 5] Figure 1 shows a simplified block d iagram of a 
Wireless Communication Device 1, in compliance with 
a preferred embodiment of the invention. The Wireless 
Communication Device 1 comprises a Control Block 5 
with preferably a Master Control Unit processor2 (MCU) 
for controlling the functions of the Wireless Communi- 
cation Device 1 , for executing Operating System rou- 
tines, etc. Furthermore, the Control Block 5 of the Wire- 
less Communication Device 1 may include a Digital Sig- 
nal Processor 3 (DSP) for signal processing functions. 
Processor 2 (MCU) and the Digital Signal Processor 3 
(DSP) are also associated with a Memory Device 4 for 
storing information and data needed by the Operating 
System, the program code, etc. The Wireless Commu- 
nication Device i also comprises a Communication De- 
vice 6, including means for performing the functions of 
a mobile phone. The information exchange between the 
user and the Wireless Communication Device 1 can 
take place via the User Interface 7 that preferably com- 
prises a Display Device 8, a Keypad 9, and Audio De- 



vices 1 0a, 1 0b, 1 0c. It is obvious that the Wireless Com- 
munication Device 1 described above is only a simplified 
example, and in practice, the Wireless Communication 
Device 1 may also comprise other Functional Blocks 

5 than those presented above. It is also true, that the Dig- 
ital Signal Processor 3 is not necessarily needed in the 
Wireless Communication Device according to the inven- 
tion, wherein the required signal processing functions 
are implemented in other blocks. In addition, the Wire- 

10 less Communication Device 1 comprises a Clock Circuit 
11 or the like, for example to generate the clock signals 
required for the functioning of the Control Block. 
[0016] Figure 2 shows simplified Functional Blocks of 
a system that is in accordance with a preferred embod- 

15 jment of the invention. This system constitutes a kind of 
a control architecture for supervising the functions of 
software processes (OS tasks) involved in the execution 
of application sessions and the use of resources of a 
wireless terminal. A software process (OS task) refers 

20 to a software entity that can be scheduled independently 
in view of the task switching function of the Operating 
System. There are several resources and resource 
types for different uses. Some examples of these re- 
sources are to be mentioned here briefly: various func- 

25 tions of the User Interface 7, such as presenting data 
on the Display Device 8, retrieval of data from the Key- 
pad 9, processing functions of audio signals; data trans- 
mission functions including the reception and genera- 
tion of various messages and the generation of re- 

30 sponse messages; signal processing functions; stacks 
of protocol software; and other application sessions. In 
the system, the Memory Device 4 also includes, e.g. a 
Message Buffer B1 for all the messages that are trans- 
mitted by Resource Handlers RH(i), RH(j), RH(k), etc. 

35 to the Application Session Manager ASM, as well as an- 
other Message Buffer B2 particularly for holding session 
initiation request messages. The Memory Device 4 of 
the system also includes, e.g. memory space for holding 
a Resource Allocation Table RAT. It is obvious that in 

40 practical applications of the invention, also other (dy- 
namic and/or fixed) memory areas can be reserved in 
the Memory Device 4 for different purposes. 
[0017] The functionality of the system can be divided 
into three main activities: Admission Control AC, Sus- 

45 pension Control SC, and Resource Reservation Control 
RRC. The Admission Control is used to restrict the ac- 
tivation of the first Activity Block Container of the Appli- 
cation Session Profile of each new session, taking into 
account the current load condition and resource reser- 
ve vation situation. The Suspension Control regulates the 
eventual suspension of the execution of individual on- 
going sessions at the end point of each Activity Block 
either temporarily or permanently according to the re- 
source reservation situation. The Resource Reservation 

55 Control is used for bookkeeping of the resource re- 
quests made by Activity Blocks of the application ses- 
sions as well as the existing resource reservations at 
each time, in order to provide this information to the Ap- 
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plication Session Manager. 

[0018] To implement the above-mentioned basic 
functionality, some Functional Blocks are specified to be 
included in the system. 

[0019] A central one among these Functional Blocks 
of the system is the management of the application ses- 
sions and resources MG, that is divided, e.g. into an Ap- 
plication Session Manager ASM and a Resource Allo- 
cation Manager RAM. The Application Session Manag- 
er ASM is responsible, e.g. for the admission and sched- 
uling the initiation of sessions, scheduling the initiation 
of the execution of individual activities included in ongo- 
ing sessions, and similar functions that are independent 
of applications. A more detailed description of the func- 
tions of this block and also other blocks of the system 
will be presented later in this specification. For the pur- 
pose of resource management and bookkeeping of the 
resource allocation situation, the system includes re- 
source-type-specific Resource Handlers RH(i) as well 
as a Resource Allocation Manager RAM. The activities 
included in the Application Session Profiles are imple- 
mented in the form of Activity Blocks which are distrib- 
uted into Activity Block Containers ABC in an appropri- 
ate manner from the viewpoint of the capacity perform- 
ance of the system, each of them containing Activity 
Blocks AB of one or more sessions. An individual Activ- 
ity Block AB may be included in different sessions when 
processed at different times. Furthermore, a Session 
Control Protocol SCP is specified for the system to con- 
trol the initiation of the execution of the Activity Blocks 
of the session, as will be described later in this applica- 
tion. Although the description of the system is composed 
of separate Functional Blocks in Fig. 2, each block is, in 
practice, preferably implemented in the form of program 
code of the Processor 2, containing the stepwise code 
needed in the functioning of these blocks. The operation 
of the system is under the task switching control exer- 
cised by the Operating System, or the like, which in ac- 
cordance with a prioritisation scheme allocates proces- 
sor time to the software processes (OS tasks) that com- 
prise all the program codes of the system. 
[0020] The term session (application session) used in 
this application may not be interpreted in a restricted 
manner, but a session may be, for example, a simple 
list of program code comprising a single activity in the 
form of a single Activity Block, or a session may consist 
of a set of separate program modules or the like which 
can be arranged into one or more Activity Blocks. A ses- 
sion may also be dependent on other sessions, for ex- 
ample if one application session initiates another appli- 
cation session to obtain some required information from 
the latter one. An application session can also be called 
an application. As non -restrictive examples of sessions 
executed in a Wireless Communication Device, one can 
give a calendar, a telephone directory, answering to an 
incoming call, creation and transmission of short text 
messages, reception and reading of short text messag- 
es, etc. In the present invention, each session is defined 



in such a way that it is composed of one or more activ- 
ities. The ordering of the execution of the Activity Blocks 
of these activities may be fixed, or the Application Ses- 
sion Manager ASM may, in the course of a session, de- 
5 termine which Activity Block is the next one to be exe- 
cuted. This selection depends, for example, on the com- 
pletion of the preceding Activity Block or the occurrence 
of a given event, the arrival of an unexpected signal, etc. 
The Activity Blocks of the same session can be located 
in, for example, a single Activity Block Container, if the 
session does not include activities that are to be execut- 
ed in parallel. 

[0021] The parallel ongoing application sessions con- 
sist of a set of successive and/or parallel activities, the 
respective Activty Blocks being located and executed in 
one ormore Activity Block Containers, depending on the 
required parallelism. For example, in the case of an in- 
coming call, a set of sessions are started one after an- 
other, to provide information of the incoming call, to re- 
trieve the name and data of the calling party from the 
telephone directory of the Wireless Communication De- 
vice on the basis of the calling number, and to display 
the name of the calling party on the display of the Wire- 
less Communication Device, and to wait for the user of 
the Wireless Communication Device to answer to the 
incoming call, in other words, preferably to stay waiting 
for eventual keystrokes. If the user presses, for exam- 
ple, the handset key, the keystroke is interpreted to de- 
cide on further activity, such as answering the call. The 
different functional phases of the above-mentioned ex- 
ample scenario can be implemented in the form of sep- 
arate application sessions or different individual activi- 
ties of a single session. Each one of said activities can 
be seen as a kind of application session. Within one ses- 
sion, however, the reservation and vacation of resourc- 
es needed by the Activity Blocks of different activities is 
more flexible than it would be if the activities were spec- 
ified to be separate application sessions. 
[0022] In the following, the primary activities of the 
central Functional Blocks will be described. The Appli- 
cation Session Manager ASM is responsible for the mu- 
tual synchronization (scheduling) of the execution of 
parallel application sessions, and the Activity Blocks in- 
cluded in these sessions, that is, providing the required 
control for the allocation and scheduling of processor 
time and other resou rces to each Activity Block. The Ap- 
plication Session Manager ASM is also responsible for 
reading Application Session Profiles ASP from an Ap- 
plication Profile Table APT. The Application Profile Table 
APT contains information, in the form of a kind of Activity 
Diagram, about the mutual precedence relationships of 
the successive and parallel Activity Blocks of the ses- 
sion (i.e., activities included in the session). On the basis 
of this Application Session Profile, the Application Ses- 
sion Manager ASM knows how the execution of the ses- 
sion shall proceed from one Activity Block to another. 
For the same application, it is also possible to specify 
more than one Application Session Profile, for example, 
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for two different use cases, for example during working 
hours and leisure time. It should be noted that the same 
Activity Block can be included in several different Appli- 
cation Session Profiles. For example, it is possible to 
start several sessions of the same application at differ- 
ent times, the Application Session Profile being each 
time different with respect to some activities. Thus, Ac- 
tivity Blocks of the same Activity Block Container can be 
included and executed within different sessions without 
a need to provide a copy of these blocks for each ses- 
sion. This yields, for example, the benefit of reducing 
the size of the Memory Device 4 needed. Preferably in 
connection with the initiation, each application session 
is assigned e.g. a priority value that can be used as an 
urgency criterion when controlling the execution order 
and possible suspension of individual sessions proc- 
essed in parallel. In addition, the estimated processing 
time and the resources required by each Activity Block 
are preferably defined for the Activity Blocks of each 
session. This information can be used by the Application 
Session Manager ASM for controlling the scheduling of 
the Activity Blocks and for the analysis of the resource 
allocation situation, particularly at the time of overload 
conditions. The Application and Session Manager ASM 
has access to a Block Assignment Table BAT of the Ac- 
tivity Blocks AB, containing a list of the Activity Blocks 
in each Activity Block Container and information of those 
blocks that are currently being processed in ongoing 
sessions. This data is stored in Block Assignment 
Records BAR in the BAT. 

[0023] In addition, the Application Session Manager 
ASM can be provided information about the resources 
needed by each Activity Block, either conditional or un- 
conditional, in the Application Profile Table APT that 
contains Application Profile Records APR. If an Appli- 
cation Session Profile does not contain information of 
all the resources needed in the session, this information 
is acquired when the Activity Blocks generate Reserva- 
tion Request messages to the Resource Handlers and 
the Resource Allocation Manager. 
[0024] The Application Session Manager ASM pref- 
erably stores history data of each session executed. For 
this purpose, the system preferably includes a Session 
History Table SHT comprising Session History Records 
SHR in which the Application Session Manager ASM 
saves trace data of each ongoing session, thus prefer- 
ably maintaining information that is transferred as output 
information from each Activity Block to the succeeding 
blocks. 

[0025] The Application Session Manager ASM re- 
ceives the initial Session Request messages appearing 
at the initiation of each new session so that the Applica- 
tion Session Manager ASM can analyse the load con- 
dition and also supervise the scheduling of the initiation 
of the activities included in the new session. Particularly 
at the time of an overload condition of the processor or 
other resources, the Application Session Manager ASM 
is responsible for deciding whether the requested ses- 



sion can be started or not. When making this decision, 
the Application Session Manager ASM preferably utiliz- 
es the processing time estimates of the Activity Blocks, 
and the related resource reservation time estimates, 
5 and possibly some other data to analyse if the more im- 
portant previously started sessions can meet their real 
time requirements also after the initiation of the new ses- 
sion. With such an arrangement, it is possibleto manage 
overload conditions largely preventing them in advance. 
10 The Application Session Manager ASM also manoeu- 
vres a temporary suspension of an application session 
at the completion of an Activity Block, for example, when 
the same reserved resource is needed forthe execution 
of some activity in a more urgent session or when a re- 
15 quired resource is entirely engaged up to the completion 
of some currently processed Activity Blocks. In practice, 
the suspension of a session can be instrumented so that 
after the end of the preceding Activity Block, the Appli- 
cation Session Manager ASM does not transmit an In- 
ward Control message (Do message) to the Activity 
Block Container that contains the next Activity Block of 
the session until this same session can be given proc- 
essor time. In some cases, an Application Session Pro- 
file may contain Activity Blocks that are intended to be 
executed in parallel, which is enabled by locating these 
blocks in different Activity Block Containers. If the 
abovementioned suspension point is precedent to the 
start of the Activity Blocks of parallel activities of this 
kind, the Inward Control message is not transmitted for 
any of these Activity Blocks until the execution of the 
session can be continued. 

[0026] It is also the responsibility of the Application 
Session Manager ASM to convey incoming messages 
from any Resource Handler in the correct order to the 
right Activity Blocks in selected Activity Block Contain- 
ers in a situation when no Activity Block is synchronous- 
ly waiting for this incoming message. This is useful par- 
ticularly in thecase of asynchronous message transmis- 
sion in a situation, in which the capacity of the same 
resource facility is shared by more than one Activity 
Block or when a preceding Reservation Request mes- 
sage has been transmitted by an Activity Block that does 
not itself pause to wait for the corresponding Reserva- 
tion Acknowledgement message (In message). Other- 
wise, an incoming message from a Resource Handler 
could be directed to an Activity Block Container or Ac- 
tivity Block more precisely, to which the message was 
not intended to go. The Application Session Manager 
ASM also supervises the releasing of resource reserva- 
tions by giving the required advisory information to the 
Activity Blocks, for example, in overload and error con- 
ditions. 

[0027] The Resource Handlers keep a list of all the 
Resource Reservation Instances Rl in corresponding 
Resource Instance Records RIR that are stored in the 
Resource Instance Table RIT of each Resource Han- 
dler. When an Activity Block in some Activity Block Con- 
tainer requests for the creation of a Resource Reserva- 
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tion Instance for itself, information about the type of the 
required Resource Reservation Instance is preferably 
sent by the Activity Block directly to the related Re- 
source Handler RH or to the Resource Allocation Man- 
ager RAM. For example, in the case of resources in- 
stalled for data transmission, it may be possible to select 
the data transmission rate, the required transmission er- 
ror rate, etc., wherein parameters affecting these char- 
acteristics of the Resource Reservation Instance can be 
provided in the Resource Reservation Instance Rl re- 
quest (Reservation Request message, Con message). 
Thus, after receiving the Reservation Request mes- 
sage, the Resource Handler RH or the Resource Allo- 
cation Manager RAM preferably examines, if a Re- 
source Reservation Instance Rl with the requested pa- 
rameter values can be created as a response to the re- 
quest from the Activity Block. A previously created Re- 
source Reservation Instance may also be existing and 
free for re-use, if it meets the parameter requirements 
of the request. An Activity Block or Activity Block Con- 
tainer can use an Outward Control message (Out mes- 
sage) to vacate its Resource Reservation Instance, 
wherein the related Resource Handler RH labels the Re- 
source Reservation Instance to be vacant in the sense 
that another Activity Block or application session can re- 
quest the reservation of the same Resource Reserva- 
tion Instance. If the creation or release of a Resource 
Reservation Instance requires that some actions are 
performed by the resource facility itself, the related Re- 
source Handler RH is aware of incomplete status of the 
creation or release operation, and the corresponding re- 
questing Activity Block or application session may need 
to wait e.g. for the acknowledgement of a Resource 
Reservation Instance. The Resource Allocation Manag- 
er is provided with information about the resource allo- 
cation situation of all the resource types. The aim of this 
arrangement is to prevent the occurrence of overload 
conditions of some resource type. 
[0028] The Application Session Manager ASM and 
the Resource Allocation Manager are preferably de- 
signed to be without intermediate delayed states, 
wherein the changes of session-related status informa- 
tion are stored in said Session History Table SHT, and 
the changes of session-related information of Resource 
Reservation Instances are stored in said Resource Al- 
location Table RAT. Also, the Resource Handlers are 
preferably designed to be without intermediate delayed 
states, wherein changes of the status data of individual 
Resource Reservation Instances are stored in the Re- 
source Instance Table RiT of each Resource Handler. 
[0029] More than one Resource Reservation Instance 
of the same resource can be existing simultaneously, 
for example, in a situation in which several Activity 
Blocks in one or more sessions need to use the same 
resource type substantially simultaneously. These Ac- 
tivity Blocks using the same resource are normally not 
located in the same Activity Block Container, but they 
can rather be in different containers in the context of dif- 



ferent sessions. In this case, it is important to ensure 
that the application-originated Reservation Request 
messages (Con messages) to the Resource Handlers 
and the corresponding Reservation Acknowledgement 
5 messages (In messages) from the Resource Handlers 
can be coupled with each other. For this purpose, the 
Resource Allocation Manager RAM is designed to per- 
form functions, that enable the Resource Allocation 
Manager RAM to handle simultaneously pending re- 

10 quests related to any single Resource Handler, for ex- 
ample, maintenance of a Waiting List and forwarding of 
each request in this order to the relevant Resource Han- 
dler at the right time. The transmission of Reservation 
Acknowledgement messages from a Resource Handler 
to the correct Activity Block Container per each Reser- 
vation Request message, is based on the assumption 
that the particular Activity Block Container that generat- 
ed the request always stays actively waiting for the cor- 
responding Reservation Acknowledgement message, 

20 and each Reservation Request message contains an 
unique Reference identifier. In the association with the 
generation of each Reservation Request message, the 
Activity Block provides the request with a Reference 
identifier, providing the Application Session Manager 

25 ASM information about the request and its Reference 
identifier for the recording of a Correlation Reference 
Record CRR in a Correlation Reference Table CRT. The 
use of Reference identifiers enables that multiple Res- 
ervation Request messages are simultaneously pend- 

30 jng and Reservation Acknowledgement messages can 
also be waited for in an asynchronous mode. 
[0030] The same Correlation Reference Table CRT is 
also used to store the Reference identifiers of those ap- 
plication messages, for which a responding application 

35 message is waited for by the application session via a 
Resource Handler (e.g. a data transmission connec- 
tion). The use of Reference identifiers enables that mul- 
tiple request messages can be simultaneously pending 
and the waiting mode can be asynchronous. 

40 [0031] An Activity Block itself also releases a Re- 
source Reservation Instance, unless the Application 
Session Manager has wanted the Resource Reserva- 
tion Instance to be kept for the succeeding or later Ac- 
tivity Blocks of the same session. In possible error situ- 

45 ations, the Application Session Manager ASM activates 
the execution of the required application-independent 
release function(s). Thus, the Resource Reservation In- 
stance will not be kept unnecessarily reserved. 
[0032] The actual processing of Reservation Request 

50 messages is performed by the Resource Handlers, one 
of them preferably established per each resource type. 
Each Resource Handler RH(i) is a software process (OS 
task of handler type) that is intended to use the Re- 
source Reservation and Outward Control messages (i. 

55 e. Reservation Request and Outward control messag- 
es) of the corresponding resource type, in the same 
manner in the case of all the different sessions and re- 
source types. In the design of the Resource Handler RH 
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(i) of each resource type i, the specific features of the 
related resource type, e.g. the processing of video sig- 
nals, audio signals, text messages, etc., are taken into 
account. The Resource Handler maintains a list of Re- 
source Reservation Instances created for the use of the 
related resource. The operation of the Resource Han- 
dlers is scheduled according to the needs determined 
by the application sessions, making use of the task 
switching functionality of the Operating System. 
[0033] The Activity Block Container ABC is a software 
process (OS task) composed of the Activity Blocks of 
one or more different Application Session Profiles and 
by the frame structure of the Activity Block Container. 
Each container normally contains several Activity 
Blocks, and the execution of these blocks is sequential 
within the same container but parallel in the case of dif- 
ferent containers. In each Activity Block Container, one 
block is the so-called Waiting Block 1 B to enable waiting 
for asynchronous events. In addition, each container 
comprises an Incoming State Module ISM, a Branching 
State Module BSM, and an Outgoing State Module TSM 
for terminating the execution thread of the Activity Block 
Container (i.e., for moving it away from the active run- 
ning state of an OS task). In addition, each Activity Block 
includes a Start State Module SSM in its beginning and 
an End State Module ESM in its end. The Activity Block 
Container ABC also comprises e.g. a list of variables, 
data structures, and memory allocations, as well as in- 
formation about the Resource Reservation Instances, 
etc., that is needed for the operation of the Activity Block 
Container. The Activity Block Container ABC receives 
messages from the Application Session Manager ASM 
to trigger the execution of Activity Blocks. In addition, 
the above-mentioned state modules and the Waiting 
Block of the Activity Block Container generate Outward 
Control messages (Out messages) of the Session Con- 
trol Protocol to the Resource Allocation Manager RAM 
that forwards them further on to the Application Session 
Manager ASM. These Outward Control messages are 
used, for example, in situations in which the execution 
of an Activity Block has been interrupted to wait until a 
specific condition is satisfied, e.g. the arrival of an ap- 
plication message to the Wireless Communication De- 
vice, or the processing of the block is completed. 
[0034] The Session Control Protocol SCP specified 
for the system of the current invention is used, for ex- 
ample, to enable co-operation of the Functional Blocks 
of the system via the delivery of Session Control Proto- 
col messages between these Functional Blocks. This is 
a kind of messaging functionality between the Function- 
al Blocks that participate in the execution of the appli- 
cation session. The Session Control Protocol SCP can 
be utilized to control the load level of the processor of 
the Wireless Communication Device to avoid and man- 
age overload conditions. In addition, the Session Con- 
trol Protocol can be used to control the scheduling of the 
initiation of individual activities during an application 
session, and to deliver process identifiers PID of the 



software processes (OS tasks) in the Functional Blocks 
of the session, as well as other application-independent 
information from one Functional Block to another. The 
Session Control Protocol can be used to prioritise the 

5 application sessions, for example, by means of the 
scheduling of individual activities included in the profiles 
of parallel sessions. The Session Control Protocol ena- 
bles the Application Session Manager to perform opti- 
mal synchronization of the reservations of shared re- 

10 sources in the system of the invention, including re- 
sources related to telecommunication connections. 
[0035] The aim has been to specify the Session Con- 
trol Protocol in a way that the actions related to resource 
reservation, e.g. Reservation Request messages (Con 

15 messages), can be performed in different application 
sessions in a uniform manner as far as possible, irre- 
spectively of the resource type. This facilitates, for ex- 
ample, to design of the code of the Activity Blocks. 
[0036] In the course of the Session Control Protocol, 

20 various messages are used to control the system and 
to transfer information between different Functional 
Blocks. In this context, these messages are referred to 
as Session Control Protocol messages, including e.g. 
the Inward Control message Do, the Outward Control 

25 message Out, the Reservation Request message Con, 
and the Reservation Acknowledgement message In. in 
addition, separate messages are needed for exception 
conditions, which need not however be discussed in 
more detail in this context. The data definition may vary 

30 in different messages, but each message preferably 
contains information about the related application ses- 
sion as well as the process identifier PID of the sender 
and receiver. Normally these messages also contain 
one or more data fields, in which data complying with 

35 the message type is transmitted to the receiver of the 
message. Messages of the Session Control Protocol 
are used to convey, for example, process identifiers of 
dynamically created or selected Resource Handlers or 
Activity Block Containers (software processes) partici- 

40 pating in the same session. 

[0037] As already stated above, the execution of an 
Activity Block is initiated by an Inward Control message 
(Do message) from the Application Session Manager 
ASM. The Inward Control message can be used to in- 

45 form the Activity Block of the resources that are availa- 
ble to the block for reservation. The Inward Control mes- 
sage can also be used to inform the Activity Block about 
the Resource Reservation Instances that should be re- 
served or released by the Activity Block. As an example, 

50 one can mention the situation of setting up a call, while 
the required communication resources are vacant. 
Thus, the Activity Block to be used for setting up the call 
can be advised to reserve the data transmission re- 
sources required for the call. After the execution of the 

55 Activity Block has been completed, it generates an Out- 
ward Control message (Out message) to the Resource 
Allocation Manager RAM. In relevant cases, this Out- 
ward Control message contains e.g. information about 
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the resources reserved or released by the Activity Block. 
In addition, this Outward Control message (Out mes- 
sage) is sent to those Resource Handlers whose Re- 
source Reservation Instances are released by the Ac- 
tivity Block either to other Activity Blocks of the same 5 
session or to other application sessions. A subsequent 
Activity Block of the same session can reserve a vacant 
Resource Reservation Instance for its use by sending 
an Outward Control message (Out message) to the re- 
lated Resource Handler, thus providing the Resource 
Handler the process identifier of the container of this Ac- 
tivity Block as an indication of this new reservation. Each 
Resource Handler only holds the identifier of one Activ- 
ity Block Container at a time, or in the absence of a vis- 
ible container a default value, e.g. the process identifier 
of the Application Session Manager or some other de- 
fault container associated with the resource type. The 
above-mentioned arrangement allows each individual 
Resource Reservation Instance to have separate visi- 
bility towards the Activity Block Containers. Since the 
high process priority of the Application Session Manag- 
er ASM helps it to get the processor essentially without 
delay after each execution turn of the Resource Alloca- 
tion Manager RAM, the resource allocation situation is 
at least partially unambiguously known at this moment 
from the viewpoint of the Application Session Manager 
ASM. Thus, the Application Session Manager ASM is 
able to find out which Activity Blocks can be activated 
and which resources can be assigned to them. 
[0038] As a summary of the resource reservation con- 
trol mechanism, it should be stated in this context that 
during its execution an Activity Block can have direct ac- 
cess to request and use a required resource, if this re- 
source happens to be vacant. For this purpose, the Ac- 
tivity Block sends a Reservation Request message di- 
rectly to the Resource Handler of the requested re- 
source type, which examines if the requested resource 
can be allocated to the requesting Activity Block. As a 
response, the Resource Handler returns a Reservation 
Acknowledgement message containing either a positive 
acknowledgement (ACK flag) or a negative acknowl- 
edgement (NACK flag), depending on whether the re- 
quested resource can or can not be allocated to the re- 
questing Activity Block at that time. Presuming that the 
control information for resource allocation provided in 
the Inward Control message from the Application Ses- 
sion manager ASM to the Activity Block is well targeted 
the Reservation Acknowledgement messages from the 
Resource Handlers are normally nonnegative. If the 
need for a resource is not necessarily immediate, or the 
above-mentioned Inward Control message indicates 
the resource to be reserved, e.g. for another use, the 
Activity Block can send the Reservation Request mes- 
sage to the Resource Allocation Manager RAM that 
manages a Waiting List. At this point, the Activity Block 
Container that contains the Activity Block transmitting 
the Reservation Request message to the Resource Al- 
location Manager RAM remains waiting for the Reser- 



vation Acknowledgement message in either synchro- 
nous or asynchronous manner. Later on, depending on 
the resource allocation situation, the Resource Alloca- 
tion Manager RAM forwards the waiting Reservation 
Request message to the related Resource Handler 
which then returns a positive Reservation Acknowl- 
edgement message directly to the Activity Block Con- 
tainer of the requesting Activity Block. To achieve this 
objective, the Application Session Manager ASM may 
have to give Inward Control messages (Do messages) 
e.g. to Activity Block Containers of some parallel appli- 
cation sessions in order to release selected Resource 
Reservation Instances. 

[0039] The functionality of the current invention can 
be largely implemented in the form of program code for 
the Processor 2 of the Wireless Communication Device 
1 . The Resource Allocation Manager and the Resource 
Handlers can be seen as a kind of Middleware layer be- 
tween the Operating System and applications of the 
Wireless Communication Device 1 . From the viewpoint 
of the Operating System, the functions in the system of 
the invention are realized by the processing of one or 
more schedulable execution threads. The invention is 
not bound to any specific Operating System, but the in- 
vention can be applied in the connection of Operating 
Systems that have a multi-task capability. However, the 
Operating System preferably meets the requirement 
that during multi-task processing the suspension of one 
schedulable process (execution thread) and the contin- 
uation of another process can only take place at pre- 
determined points of the program code instead of any 
arbitrary point. The designer of the program code de- 
fines and sets those points in which the Operating Sys- 
tem can switch the process executed (OS task). These 
kind of suspension capabilities are preferably located at 
those points where the processing of the code of an Ac- 
tivity Block Container or the entire application session 
can be interrupted for a natural reason, for example 
when waiting for a response from a Resource Handler. 
[0040] In the following, the operation of a method cor- 
responding to a preferred embodiment of the invention 
will be described with reference to the example situation 
shown in Fig. 4. In the figure, the arrows indicated with 
solid lines illustrate the transmission of messages be- 
tween different blocks, the arrows with broken lines il- 
lustrate the procedure of executing an application ses- 
sion one activity after another, and the arrows with dot- 
ted lines illustrate the transmission of Session Control 
Protocol messages of the application session between 
the blocks. 

[0041 ] Let us assume that the Wireless Communica- 
tion Device 1 has been turned on and the Operating Sys- 
tem is started. At some stage, the Operating System 
preferably starts the operation of the system corre- 
sponding to the invention by activating the operations to 
initialise the Application Session manager ASM, the Re- 
source Allocation Manager RAM, and the Session Con- 
trol Protocol SCP. At the time when an application ses- 
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sion is to be started, an application session request is 
conveyed to the Application Session Manager ASM. 
The initiation of the application session may be caused 
by a request from another application session, an exter- 
nal event such as an incoming call to the wireless ter- 5 
minal 1 , a key pressed by the user of the wireless ter- 
minal 1 , etc. In the situation of Fig. 4, a text message 
has arrived to the wireless terminal 1 causing the initia- 
tion of a new application session. The Resource Handler 
RH(1) of the connection type of the received text mes- 10 
sage has transmitted a Session Request message S1 
that has been placed in the Message Buffer B1 . The Ap- 
plication Session Manager ASM detects the arrival of 
the message in the Message Buffer B1 , reads the par- 
ticular data field of the message needed for the identif i- 15 
cation of the requested application session, and then 
reads the session profile of the application session to 
be started in the Application Profile Table APT. At this 
point, the history profile data of the current application 
session is initialised in the Session History Table SHT. 20 
The Application Session Profile ASP discloses, e.g., the 
activities included in the session and possibly the Re- 
source Reservation Instances needed correspondingly 
as well as the estimated processing times specified per 
each Activity Block. On the basis of the profiles of the 25 
ongoing sessions processed or suspended, the data 
contents of the Resource Allocation Table RAT, and the 
profile of the session to be started, the Application Ses- 
sion Manager ASM performs an analysis to find out 
whether the session can be started or not. The Applica- 30 
tion Session Manager ASM calculates an estimate of 
the increased load of the Processor 2 caused by starting 
the session. In addition, the Application Session Man- 
ager ASM analyses the resource allocation situation of 
those resources needed by the session to be started, 35 
estimating the load level of these resources too. If the 
Application Session Manager ASM makes a decision to 
start the session, the Application Session Manager ASM 
selects some Activity Block Container ABC in which the 
Activity Block of the first activity of the session profile of *o 
the current session is included. The selected Activity 
Block Container ABC is loaded into the memory Device 
4 for the execution of the abovementioned first Activity 
Block, unless it is already in the memory and available 
for execution. In the example of Fig. 4, the application 45 
session to be started contains a set of activities, which 
correspond to Activity Blocks 0B-11B. The execution of 
the session is started by activating the first Activity Block 
OB at the time when the Activity Block Container ABC 
of this Activity Block gets the processor after the above- so 
mentioned downloading. As already stated above in this 
description, the relative urgency of the application ses- 
sions with respect to each other can be determined in 
order to use it as a basis for controlling the allocation of 
processor time to each session as well as to control the 55 
execution order of the sessions. 

[0042] From the Message Buffer B1 , the Application 
Session Manager ASM moves the received Session Re- 
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quest message S1 from the Message Buffer B1 to an- 
other Message Buffer B2 essentially at the same mo- 
ment when it gets processor time from the Operating 
System. At the time when the execution of a new appli- 
cation session can be started, the Application Session 
Manager ASM transmits an Inward Control message 
(Do message) to the selected Activity Block Container 
ABC that contains the first Activity Block OB of the ses- 
sion. As a result, the execution of the Activity Block OB 
is initiated. In this example, after the execution of the 
Activity Block OB has been completed and the corre- 
sponding Outward Control message (Out message) has 
been returned to the Resource Allocation Manager 
RAM, the Application Session Manager ASM (after hav- 
ing received this Outward Control message from the Re- 
source Allocation Manager RAM) transmits, on the ba- 
sis of the Application Session Profile, an Inward Control 
message (Do message) to three Activity Block Contain- 
ers ABC1 , ABC2, ABC3 for the execution of three Ac- 
tivity Blocks 1B, 2B, 3B respectively, with the intention 
to establish connections of these different types in par- 
allel. In this example, these connection types are audio, 
data and video, respectively. Each Activity Block 1 B, 2B, 
3B transmits a Reservation Request message (Con 
message) to the Resource Handler RH(2), RH(3), RH 
(4) of its connection type respectively. Each Reservation 
Request message contains relevant information, such 
as the process identifier or some other identifier of the 
Activity Block Container that generates the message. By 
means of this information, the Resource Handlercan re- 
turn a Reservation Acknowledgement message (In 
message) to the correct Activity Block Container. The 
Resource Handler returns a Reservation Acknowledge- 
ment message (In message) after it has transmitted the 
Reservation Request message (Con message) from the 
Activity Block Container to the connection protocol pro- 
gram and also received an acknowledgement of the es- 
tablishment of this connection from the protocol pro- 
gram. Thus, the Activity Block in the Activity Block Con- 
tainer receives either a negative Reservation Acknowl- 
edgement message or a positive one as an indication 
that the Resource Handler has, within the capacity lim- 
its, allocated a Resource Reservation Instance to the 
application session and that the Resource Handler has 
performed any initialising and recording actions possibly 
required for using the resource. In addition, it is an aim 
of the Resource Handler to transmit application mes- 
sages received from the related connection protocol 
program always to the Activity Block Container that par- 
ticipates in the execution of the application session and 
has provided its identifier to the Resource Handler. The 
application session will preferably pause to a waiting 
state at the time when it stops to wait forthe related Res- 
ervation Acknowledgement message (In message) 
from the Resource Handler after the transmission of a 
Reservation Request message (Con message). Infor- 
mation about the beginning of this waiting state is pref- 
erably delivered to the Resource Allocation Manager 
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RAM by means of an Outward Control message (Out 
message) at the same time with the transmission of 
each Reservation Request message. In the Activity 
Block 48 of Fig. 4, it is waited that a Reservation Ac- 
knowledgement message is obtained as a response to 5 
all the three Reservation Request messages before it is 
time to proceed to the generation of data to be transmit- 
ted from the wireless terminal 1 along the different con- 
nection types. In the case of a general application ses- 
sion, the Activity Blocks 5B, 6B and 7B can use different 10 
connection types on behalf of this session to interactive- 
ly exchange application messages with the applications 
at the other ends of the connections, wherein it is ben- 
eficial that the Activity Blocks 5B, 6B and 7B are located 
in three separate Activity Block Containers. In the gen- *5 
eral case, an application session may contain a much 
larger number of Activity Blocks that are executed in par- 
allel. 

[0043] The scheduling of the operation of the Re- 
source Handlers is arranged by means of the function- 20 
ality and scheduling mechanism of the Operating Sys- 
tem so that the actions of the Resource Handlers are 
executed right after the Activity Blocks have sent mes- 
sages to them for processing. The Resource Handlers 
are furnished with an interface, through which the Activ- 25 
ity Block Containers are able to send Session Control 
Protocol messages and outgoing application messages 
to the Resource Handlers and, vice versa, to receive 
messages correspondingly from the Resource Han- 
dlers. This interface is independent of the applications 30 
and substantially also independent of the resource type, 
which enables the use of substantially standard mes- 
sages in the Session Control Protocol. In addition, the 
Resource Handler transmits application messages both 
from the Activity Block Containers to the resource facility 35 
and vice versa from this facility to the Activity Block Con- 
tainers and/or the Application Session Manager ASM. 
Per each Reservation Request message, the Resource 
Handlers create a reservation (Resource Reservation 
Instance Rl) which is a kind of a definition of the Re- *o 
source Reservation Instance including parameters re- 
lated to the use of this reservation, such as the data 
transmission rate, resolution of the display, stereo ver- 
sus mono voice output, etc. Resource Reservation In- 
stances are registered as Resource Instance Records 45 
RIR in a Resource Instance Table RIT. Each Resource 
Handler is associated with a Resource Instance Table 
of its own. Each Resource Handler takes care of its own 
Resource Reservation Instances and provides informa- 
tion about them to the Resource Allocation Manager so 
RAM. Consequently, the Resource Allocation Manager 
RAM preferably holds the bookkeeping data of all the 
existing Resource Reservation Instances in the Re- 
source Allocation Table RAT. 

[0044] The Resource Allocation Manager RAM offers 55 
the data contents of the Resource Allocation Table to 
the Application Session Manager ASM, that uses this 
information e.g. to bring the processing of different ap- 



plication sessions from a suspension state to an active 
processing state. The Resource Allocation Manager 
RAM also receives the Outward Control messages gen- 
erated by the Activity Block Containers, such as infor- 
mation of the completion of the execution of an Activity 
Block, or the beginning of a synchronous waiting state 
within an Activity Block, or the arrival of a Reservation 
Acknowledgement message from a Resource Handler 
to an Activity Block Container. 

[0045] After the Resource Allocation Manager RAM 
has provided the data contents of the Resource Alloca- 
tion Table to the Application Session Manager ASM , the 
Processor 2 starts executing the code of the Application 
Session Manager ASM that selects the next application 
session and more precisely the next Activity Block to be 
executed. As a selection criterion, the Application Ses- 
sion Manager ASM uses e.g. the resource allocation sit- 
uation and the load level of the Processor 2. An Inward 
Control message (Do message) is preferably transmit- 
ted to the selected Activity Block Container that contains 
this kind of Activity Block in order to initiate the execution 
of the Activity Block. More than one Activity Block can 
be processed substantially at the same time assuming 
that they are included in separate Activity Block Con- 
tainers (so-called parallel software processes). In prac- 
tice, this means that the Processor 2 executes the code 
of these Activity Block Containers in an alternating man- 
ner. As an example of this kind of parallelism, there are 
firstly Activity Blocks 1 B, 2B, 3B, and secondly 5B, 6B, 
7B and thirdly 8B, 9B, 1 0B in the example of Fig. 4. How- 
ever, in multiprocessor systems, true parallel process- 
ing is also possible for the execution of the code in the 
Activity Block Containers. 

[0046] Let us assume that processor time is given to 
the Activity Blocks 5B, 6B, 7B that make up the data 
contents of audio, data and video types to be sent out 
from the wireless terminal 1 , as well as the application 
messages required for the control of this data transmis- 
sion. In other words, these Activity Blocks 5B, 6B, 7B 
generate the data contents for the transmission and 
transmit the necessary application messages to the cor- 
responding Resource Handlers RH(2), RH(3), RH(4). 
These messages are indicated with the reference labels 
D, E, F in Fig. 4. The Resource Handlers perform the 
functions required to transmit the data contents of these 
three different types from the wireless terminal 1 . After 
these three data transmission activities are accom- 
plished, Outward Control messages (Out messages) 
are generated by the Activity Blocks 8B, 9B, 1 0B to re- 
lease the three Resource Reservation Instances re- 
spectively. After this, the execution of the application 
session can be completed by executing the terminating 
block 11 B. The memory spaces allocated for the use- 
less Activity Block Containers ABC1 , ABC2, ABC3 can 
be released and the parameter data of the Resource 
Reservation instances used by the terminated session 
can be deleted in the Resource Instance Tables RIT and 
the Resource Allocation Table RAT. 
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[0047] The processing of the next Session Request 
message S2 is performed in accordance with the prin- 
ciples presented above. 

[0048] Fig. 3 also shows the structure of an Activity 
Block Container ABC and the progression of the execu- 5 
tion of the Activity Blocks in the Activity Block Container 
ABC. The Activity Block Containercontains an Incoming 
State Module ISM that is always executed at the time 
when a vacant Activity Block Container receives the first 
activating Inward Control message. After that, the Ac- 10 
tivity Block Container contains a Branching State Mod- 
ule BSM that reads the identifier of the next Activity 
Block to be executed in order to find out to which Activity 
Block AB1 , AB2, AB3 the execution thread of the Activity 
Block Container should be taken. The end point of each *5 
Activity Block is equipped with an End State Module 
ESM that signals the completion of the block to the Re- 
source Allocation Manager RAM by means of an Out- 
ward Control message (Out message) and thereby fur- 
ther to the Application Session Manager ASM, after 20 
which the execution thread of the Activity Block Contain- 
er ABC is taken to wait for the next Inward Control mes- 
sage (Do message) in order to be able to continue the 
execution of the session from the next Activity Block on- 
wards as soon as this block container gets processor 25 
time from the Operating System. For this purpose, the 
execution thread is taken from the End State Module 
ESM to the beginning of the Waiting Block IB where a 
Waiting State Module ISM located for the reception of 
any messages from the Resource Handlers to the Ac- 30 
tivity Block Container. This kind of message is received 
by the Waiting Block and preserved in a specific Tem- 
porary Message Buffer, after which the Transition State 
Module FSM at the end of the Waiting Block generates 
an Outward Control message (Out message) to the Re- 35 
source Allocation Manager RAM and further on to the 
Application Session Manager ASM, informing them 
about the received message. The processing of the 
Waiting Block IB ends when the execution thread of the 
Activity Block Container is taken to the beginning of any *o 
embedded Activity Block on the basis of the next Inward 
Control message (Do message) received by the Waiting 
State Module ISM. In this case, the execution thread is 
deviated from the Transition State Module FSM in the 
end of the Waiting Block IB via the Branching State Mod- *s 
ule BSM to the beginning of the Activity Block to be proc- 
essed next. The Application Session Manager ASM can 
use a particular parameter of the Inward Control mes- 
sage to instruct the execution control to be directed from 
the Waiting Block after the Transition State Module FSM so 
to the Outgoing State Module TSM of the Activity Block 
Container, in order to terminate the execution control of 
the block container and to release the container. After 
the Outgoing State Module TSM, the Activity Block Con- 
tainer is free, in view of the Application Session Manager ss 
ASM, to be selected for the execution of any Activity 
Block therein, in the context of any application session. 
When the message received by the Waiting Block IB 



does not deviate the execution thread to the Branching 
State Module BSM or the Outgoing State Module TSM, 
the execution control will always return from the Transi- 
tion State Module FSM of the Waiting Block IB to the 
Waiting State Module ISM in the beginning of the Wait- 
ing Block IB to continue the idle waiting. 
[0049] In those situations where the load of the Proc- 
essor 2 is relatively low, the Application Session Man- 
ager ASM can adjust the power consumption of the 
Processor 2 to be lower, e.g. by reducing the clock fre- 
quency. On the other hand, in the case of some proces- 
sors the power consumption can be regulated by setting 
at least some of those Functional Blocks of the proces- 
sor, that are not needed at the moment, into a power 
saving mode. 

[0050] To a great extent, the current invention can be 
implemented in the form of software, for example as ex- 
ecutable instructions of the Processor 2. 
[0051] It is obvious that the current invention is not 
limited solely to the above-presented embodiments on- 
ly, but it can be modified within the scope of the append- 
ed claims. 



Claims 

1 . A system comprising means (2, 4) for executing ap- 
plication sessions in an electronic device (1) with 
one or more processors (2), and means (2) for 
scheduling Resource Reservation Instances (Rl) as 
well as the execution of substantially simultaneous 
application sessions, characterized in that the ap- 
plication session to be executed comprises one or 
more Activity Blocks (AB) in one or more Activity 
Block Containers (ABC, ABC1 , ABC2, ABC3), and 
an execution order is specified for said Activity 
Blocks (AB); that the system comprises resource 
type specific Resource Handlers (RH) for reserving 
resources for the application session, Resource Al- 
location Manager (RAM, RAT, RH, RIT) for analys- 
ing and saving the resource allocation situation, Ap- 
plication Session Management and Scheduling 
means (ASM) for selecting at least the next appli- 
cation session and Activity Block to be executed on 
the basis of said resource allocation situation, exe- 
cuting means (2, AC) for executing the next Activity 
Block (AB) in the course of the selected application 
session, and the system is provided with a protocol 
(SCP) connecting the Resource Handlers (RH), Re- 
source Allocation Manager (RAM, RAT, RH, RIT), 
Application Session Management and Scheduling 
means (ASM) and executing means (2, AC), to con- 
trol the execution order and to implement the trans- 
fer of information between said Resource Handlers 
(RH), Resource Allocation Manager (RAM, RAT, 
RH, RIT), Application Session Management and 
Scheduling means (ASM), and executing means (2, 
AC). 
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2. The system in accordance with Claim 1 , character- 
ized in that it comprises means (RAM, RAT, RH, 
RIT) for bookkeeping of the resource allocation sit- 
uation, means (ASM, Do) for transmitting a first con- 
trol message (Do) to an Activity Block (AB) to pro- 
vide control information on the resource allocation 
to the Activity Block (AB) at the time of the initiation 
of the Activity Block (AB), and means for transmit- 
ting a second control message (Out) at the time of 
the completion of the execution of the Activity Block 
(AB) to provide information about the resources re- 
served or released by the Activity Block (AB) to up- 
date the bookkeeping of the resource allocation sit- 
uation after the completion of each Activity Block 
(AB). 

3. The system according to Claim 2, characterized in 
that it comprises means (ASM, ABC, SCP, RAM, 
RAT, RH, RIT) for an application session to reserve 
the resources needed by each Activity Block (AB), 
as well as to release them, either directly from the 
resource type specific Resource Handlers (RH) or 
from the Resource Allocation Manager (RAM, RAT, 
RH, RIT) that enable the queuing of reservation re- 
quest messages, on the basis of control parameters 
received in a first control message (Do) received 
from Application Session Management and Sched- 
uling means (ASM). 

4. The system in accordance with Claim 2 or 3, char- 
acterized in that it comprises means (ABC, SCP, 
RIT, RH) for making the Resource Reservation In- 
stances created on a request from the application 
session, via the use of second Control messages 
(Out), dynamically available to different Activity 
Block Containers involved in the execution of the 
session, as needed. 

5. The system in accordance with any of the Claims 1 
to 4, characterized in that the system comprises 
an Operating System with scheduling functions, 
and that for synchronizing the reservation, release 
and other resource- related control from the Appli- 
cation Session Management and Scheduling 
means (ASM), Activity Block Containers (ABC, 
ABC1 , ABC2, ABC3), Resource Allocation Manag- 
er (RAM, RAT, RH, RIT), and Resource Handlers 
(RH), there is a Session Control Protocol (SCP) 
composed of application-independent control mes- 
sages and rules on their use, which is arranged dur- 
ing its operation to implement the synchronization 
and scheduling control of the execution of the Ap- 
plication Session Management and Scheduling 
means (ASM), the Activity Block Containers (ABC, 
ABC1 , ABC2, ABC3), the Resource Allocation Man- 
ager (RAM), as well as the Resource Handlers 
(RH), on the basis of the task switching functions of 
the Operating System as well as the OS task prior- 



ities defined for the Application Session Manage- 
ment and Scheduling means (ASM), the Activity 
Block Containers (ABC, ABC1, ABC2, ABC3), the 
Resource Allocation Manager (RAM, RAT, RH, 
5 RIT), and the Resource Handlers (RH). 

6. The system in accordance with any of the Claims 1 
to 5, characterized in that it comprises a Resource 
Instance Table (RIT) per each Resource Handler 

10 (RH) to provide the resource allocation situation to 
said resource management and allocation means 
(RAM), and that the synchronization of the Re- 
source Allocation Manager (RAM, RAT, RH, RIT) 
with respect to the Resource Handlers (RH) is de- 

15 termined so that substantially immediately after 
each execution turn of the Resource Handlers (RH) 
it is the turn of the Resource Allocation Manager 
(RAM), wherein the resource allocation situation is 
unambiguously known in the Resource Instance Ta- 

20 bles (RIT) regarding the latest changes occurred. 

7. The system in accordance with Claim 6, character- 
ized in that the synchronization of the Resource Al- 
location Manager (RAM, RAT, RH, RIT) with respect 

25 to the Application Session Management and 
Scheduling means (ASM) is determined so that 
substantially immediately after each execution turn 
of the Resource Allocation Manager (RAM, RAT, 
RH, RIT) it is the turn of the Application Session 

30 Management and Scheduling means (ASM), 
wherein the resource allocation situation is unam- 
biguously known regarding the latest changes oc- 
curred, and values can be determined by the Appli- 
cation Session Management and Scheduling 

35 means for the parameters of the control messages 
generated by it for the synchronization of the use of 
various types of Resource Reservation Instances 
(Rl). 

40 8. The system in accordance with any of the Claims 1 
to 7, characterized in that an End State Module 
(ESM) is placed at the end of each Activity Block 
(AB) to complete the execution of the block, and a 
Waiting State Module (ISM) is placed in the Activity 

45 Block Container holding the Activity Block, and that 
the execution control of the Activity Block Container 
(ABC, ABC1 , ABC2, ABC3) holding the Activity 
Block (AB) is arranged to generate a second Con- 
trol message (Out) in the End State Module (ESM) 

50 and to pause the execution in the Waiting State 
Module (ISM) in order to wait for a first control mes- 
sage (Do) from the Application Session Manage- 
ment and Scheduling means (ASM), wherein the 
execution of the application session is temporarily 

55- interrupted regarding the current Activity Block 
Container (ABC, ABC1 , ABC2, ABC3). 

9. The system in accordance with Claim 8, character- 
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ized in that the Application Session Management 
and Scheduling means (ASM) are arranged to an- 
alyse the resource allocation situation and the 
scheduling of the sessions to be executed to detect 
an overload condition of one or more resources and 
to manage it by replacing, as needed, application 
sessions with other application sessions requiring 
less resources, or by delaying, as needed, the 
transmission of first control messages (Do) to the 
application sessions, which results in a temporary 
suspension of the ongoing application session or in 
a delayed initiation of a new application session. 

10. The system in accordance with any of the Claims 1 
to 9, characterized in that the Activity Blocks (AB) 
of the application session are placed in one or more 
Activity Block Containers (ABC, ABC1 , ABC2, 
ABC3), that Activity Blocks in any one of these Ac- 
tivity Block Containers (ABC, ABC1 , ABC2, ABC3) 
are arranged to be executed temporally at different 
times, and in the presence of Activity Blocks (AB) 
that are intended to be executed substantially at the 
same time in the course of the session, they are 
placed in different Activity Block Containers (ABC, 
ABC1 , ABC2, ABC3). 

11. The system in accordance with Claim 10, charac- 
terized in that for designing applications that are 
to be executed in the system, each Activity Block 
Container (ABC, ABC1 , ABC2, ABC3) is furnished 
with an interface module at those points where the 
execution of an Activity Block (AB) or the Activity 
Block Container (ABC, ABC1 , ABC2, ABC3) can be 
interrupted and it may be the turn of another OS task 
to be executed, thus enabling the sending and re- 
ception of Session Control Protocol messages to 
take place via this interface of the Activity Block 
Container (ABC, ABC1, ABC2, ABC3) without a 
need to deal with these messages of the protocol 
as part of the application design work. 

12. The system in accordance with the Claims 1 to 11 , 
characterized in that the Resource Handlers (RH) 
are equipped with an interface for transmitting in- 
formation between each Resource Handler and the 
system, this interface being substantially independ- 
ent of the application session and the resource type. 

13. The system in accordance with the Claims 1 to 12, 
characterized in that it comprises a dedicated Re- 
source Instance Table RIT in the use of each Re- 
source Handler (RH), and that the Resource Han- 
dlers (RH) are designed to be without intermediate 
delayed states, wherein the changes of the status 
data of individual Resource Reservation Instances 
are stored in the Resource Instance Table (RIT) of 
each Resource Handler (RH). 



14. The system in accordance with the Claims 1 to 13, 
characterized in that the Application Session 
Management and Scheduling means (ASM) are as- 
sociated with a Session History Table (SHT) and the 

5 Resource Allocation Manager are associated with 

a Resource Allocation Table (RAT), and that the Ap- 
plication Session Management and Scheduling 
means (ASM) and the Resource Allocation Manag- 
er are designed to be without intermediate states, 

10 wherein the changes of session-related status in- 
formation is stored in said Session History Table 
(SHT), and the changes of session-related informa- 
tion of Resource Reservation Instances are stored 
in said Resource Allocation Table (RAT). 

15 

15. The system in accordance with the Claims 1 to 14, 
characterized in that it comprises means ASM to 
determine the load condition of the processor and 
to adjust the power consumption of the processor 

20 on the basis of the load condition through the sched- 
uling of the activities of the application sessions. 

16. A method for executing application sessions in an 
electronic device (1) with one or more processors 

25 (2) for synchronizing Resource Reservation In- 
stances (Rl) as well as the execution of substantial- 
ly simultaneous application sessions, character- 
ized in that the application session to be executed 
comprises one or more Activity Blocks (AB) in one 

30 or more Activity Block Containers (ABC, ABC1, 
ABC2, ABC3), and an execution order is deter- 
mined for said Activity Blocks (AB), that the method 
comprises at least the following steps: 

35 a resource management and allocation step for 

requesting and reserving resources for the ap- 
plication session, 

a bookkeeping and analysis step forsaving and 
analysing the resource reservation situation, 
40 a scheduling and selection step for selecting 

the next application session and Activity Block 
(AB) to be executed at least on the basis of said 
resource reservation situation, 
an execution step for executing the next Activity 
45 Block (AB) in the course of the selected appli- 

cation session, 

wherein in the method, a communication protocol 
(SCP) connecting said resource management and 
so allocation step, bookkeeping and analysis step, 
scheduling and selection step, and the execution 
step are used to control the execution order and, if 
necessary, to transfer information between said re- 
source management and allocation step, book- 
55 keeping and analysis step, scheduling and selec- 
tion step, and execution step. 

17. The method in accordance with Claim 16, charac- 
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terized in that a bookkeeping of the resource allo- 
cation is maintained, and an first control message 
(Do) is transmitted to an Activity Block to provide 
control information on the resource allocation at the 
time of the initiation of the Activity Block, and a sec- 5 
ond Control message (Out) is returned by the Ac- 
tivity Block to provide information about the resourc- 
es reserved or released by the Activity Block to up- 
date the bookkeeping of the resource allocation sit- 
uation after the completion of each Activity Block. 10 

18. The method in accordance with Claim 1 7, charac- 
terized in that the resources needed by each Ac- 
tivity Block (AB) are reserved and released by the 
application session, either directly from resource 15 
type specific Resource Handlers (RH) or from the 
Resource Allocation Manager (RAM, RAT, RH, RIT) 
that enable the queuing of Reservation Request 
messages, on the basis of control parameters re- 
ceived in a first control message (Do) received from 20 
Application Session Management and Scheduling 
means (ASM). 

19. The method in accordance with Claim 17 or 18, 
characterized in that second control messages 25 
(Out) are used by the application session to dynam- 
ically assign Resource Reservation Instances (Rl) 

to the use of different Activity Block Containers 
(ABC, ABC1 , ABC2, ABC3) involved in the execu- 
tion of the session, as needed. 30 

20. The method in accordance with any of the Claims 
16 to 19, characterized in that in the method, an 
Operating System is utilized comprising task 
switching functions, and that for synchronizing the 35 
reservation, release and other resource-related 
control from the Application Session Management 
and Scheduling means, Activity Block Containers 
(ABC, ABC1, ABC2, ABC3), Resource Allocation 
Manager and the Resource Handlers (RH), there is *o 
a Session Control Protocol (SCP) composed of ap- 
plication-independent control messages and rules 

on their use, which is arranged, during its operation, 
to implement the synchronization and scheduling 
control of the execution of the Application Session 45 
Management and Scheduling means, the Activity 
Block Containers (ABC, ABC1, ABC2, ABC3), the 
Resource Allocation Manager, as well as the Re- 
source Handlers (RH), on the basis of the task 
switching functions of the Operating System as well 50 
as the OS task priorities defined for the Application 
Session Management and Scheduling means, the 
Activity Block Containers (ABC, ABC1 , ABC2, 
ABC3), the Resource Allocation Manager, and the 
Resource Handlers (RH). 55 

21 . The method in accordance with any of the Claims 
16 to 20, characterized in that in the method, a 



Resource Instance Table (RIT) is used per each Re- 
source Handler (RH) to provide the resource allo- 
cation situation to said Resource Allocation Manag- 
er (RAM), and that the synchronization of the book- 
keeping and analysis step with respect to the re- 
source management and allocation step of the Re- 
source Handlers (RH) is determined so that sub- 
stantially immediately after each execution turn of 
the Resource Handlers (RH), it is the turn of the 
bookkeeping and analysis step, wherein the re- 
source allocation situation is unambiguously known 
in the Resource Instance Tables (RIT) regarding the 
changes occurred. 

22. The method in accordance with Claim 21 , charac- 
terized in that the scheduling of the scheduling and 
selection step with respect to the bookkeeping and 
analysis step is determined so that the scheduling 
and selection step is in turn substantially immedi- 
ately after the execution of the bookkeeping and 
analysis step, wherein the resource allocation situ- 
ation is unambiguously known in the Resource Al- 
location Table (RAT) regarding the latest changes 
occurred, and values can be determined by the Ap- 
plication Session Management and Scheduling 
means (ASM) for the parameters of the control mes- 
sages generated by it for the synchronization of the 
use of various types of Resource Reservation In- 
stances (Rl). 

23. The method in accordance with any of the Claims 
16 to 23, characterized in that an End State Mod- 
ule (ESM) is placed at the end of each Activity Block 
(AB) to complete the execution of the block, and a 
Waiting State Module (ISM) Is placed in the Activity 
Block Container (ABC, ABC1 , ABC2, ABC3) hold- 
ing the Activity Block, and that the execution control 
of the Activity Block Container (ABC, ABC1 , ABC2, 
ABC3) holding the Activity Block is arranged to gen- 
erate a second control message (Out) in the End 
State Module (ESM) and to pause the execution in 
the Waiting State Module (ISM) in order to wait for 
an first control message (Do) from the Application 
Session Management and Scheduling means, 
wherein the execution of the application session is 
temporarily interrupted regarding the current Activ- 
ity Block Container (ABC, ABC1 , ABC2, ABC3). 

24. The method in accordance with Claim 23, charac- 
terized in that the Application Session Manage- 
ment and Scheduling means (ASM) analyse the re- 
source allocation situation and the scheduling of the 
sessions to be executed to detect an overload con- 
dition of one or more resources and to manage it by 
replacing, as needed, application sessions with oth- 
er application sessions requiring less resources, or 
by delaying, as needed, the transmission of first 
control messages (Do) to the application sessions, 
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which results in a temporary suspension of the on- 
going application session, or in a delayed initiation 
of a new application session. 

25. The method in accordance with any of the Claims 
16 to 24, characterized in that the Activity Blocks 
(AB) of the application session are placed in one or 
more Activity Block Containers (ABC, ABC1 , ABC2, 
ABC3), that Activity Blocks (AB) in any one of these 
Activity Block Containers (ABC, ABC1 , ABC2, 
ABC3) are arranged to be executed temporally at 
different times, and in the presence of Activity 
Blocks (AB) that are intended to be executed sub- 
stantially at the same time in the course of the ses- 
sion, they are placed in different Activity Block Con- 
tainers (ABC, ABC1 , ABC2, ABC3). 

26. The method in accordance with Claim 25, charac- 
terized in that for designing applications that are 
to be executed in the system, each Activity Block 
Container (ABC, ABC1 , ABC2, ABC3) is furnished 
with an interface module at those points where the 
execution of an Activity Block or Activity Block Con- 
tainer (ABC, ABC1 , ABC2, ABC3) can be interrupt- 
ed and it may be the turn of another Operating Sys- 
tem task to be executed, thus enabling the sending 
and reception of Session Control Protocol messag- 
es to take place via this interface of the Activity 
Block Container (ABC, ABC1, ABC2, ABC3) with- 
out a need to deal with these messages of the Ses- 
sion Control Protocol as part of the application de- 
sign work. 

27. The method in accordance with any of the Claims 
1 6 to 26, characterized in that the Resource Han- 
dlers (RH) are equipped with an interface for trans- 
mitting information between each Resource Han- 
dler (RH) of the system, this interface being sub- 
stantially independent of the application session 
and the resource type. 

28. The method in accordance with any of the Claims 
16 to 27, characterized in that a dedicated Re- 
source Instance Table (RIT) is in the use of each 
Resource Handler (RH), and that the Resource 
Handlers (RH) are designed to be without interme- 
diate delayed states, wherein the changes of the 
status data of individual Resource Reservation In- 
stances (Rl) are stored in the Resource Instance Ta- 
ble (RIT) of each Resource Handler (RH). 

29. The method in accordance with any of the Claims 
16 to 28, characterized in that a Session History 
Table (SHT) is in the use of the scheduling and se- 
lection step, and a Resource Allocation Table (RAT) 
is in the use of the bookkeeping and analysis step, 
that the resource management and allocation step, 
bookkeeping and analysis step, as well as sched- 



uling and selection step are designed to be without 
intermediate delayed states, wherein the changes 
of session-related status information is stored in 
said Session History Table (SHT), and the changes 
5 of session-related information of the Resource Res- 

ervation Instances (Rl) are stored in said Resource 
Allocation Table (RAT). 

30. The method in accordance with any of the Claims 
10 16 to 29, characterized in that the load condition 

of the processor is determined, and that the power 
consumption of the processor is adjusted on the ba- 
sis of the load condition through the scheduling of 
the activities of the application sessions. 

15 

31 . An electronic device (1 ) comprising means (2, 4) for 
executing application sessions, one or more proc- 
essors (2), and means (2) for scheduling Resource 
Reservation Instances (Rl) as well as the execution 

20 of substantially simultaneous application sessions, 
characterized in that the application session to be 
executed comprises one or more Activity Blocks 
(AB) in one or more Activity Block Containers (ABC, 
ABC1 , ABC2, ABC3), and an execution order is de- 

25 termined for said Activity Blocks (AB); that the elec- 
tronic device (1) comprises resource type specific 
Resource Handlers (RH) for reserving resources for 
the application session, Resource Allocation Man- 
ager (RAM, RAT, RH, RIT) for analysing and saving 

30 a resource allocation situation, Application Session 
Management and Scheduling means (ASM) for se- 
lecting at least the next application session and Ac- 
tivity Block to be executed on the basis of said re- 
source allocation situation, executing means (2, 

35 AC) for executing the next Activity Block (AB) in the 
course of the selected application session; and the 
electronic device (1) is provided with a protocol 
(SCP) connectingthe Resource Handlers (RH), Re- 
source Allocation Manager (RAM, RAT, RH, RIT), 

40 Application Session Management and Scheduling 
means (ASM) and executing means (2, AC), to con- 
trol the execution order and to implement the trans- 
fer of information between said Resource Handlers 
(RH), Resource Allocation Manager (RAM, RAT, 

45 rh, RIT), Application Session Management and 
Scheduling means (ASM), and executing means (2, 
AC). 

32. The electronic device (1) in accordance with Claim 
50 31 , characterized in that it is a wireless communi- 
cation device. 

33. A software program comprising machine executa- 
ble steps for executing application sessions in an 

55 electronic device (1) with me or more processors 
(2) for synchronizing Resource Reservation In- 
stances (Rl) as well as the execution of substantially 
simultaneous application sessions, characterized 
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in that the application session to be executed com- 
prises one or more Activity Blocks (AB) in one or 
more Activity Block Containers (ABC, ABC1 , ABC2, 
ABC3), and an execution order is determined for 
said Activity Blocks (AB), that the software program 5 
further comprises machine executable steps for 
performing at least the following steps: 



a resource management and allocation step for 
requesting and reserving resources for the ap- 10 
plication session, 

a bookkeeping and analysis step for saving and 
analysing the resource reservation situation, 
a scheduling and selection step for selecting 
the next application session and Activity Block 15 
(AB) to be executed at least on the basis of said 
resource reservation situation, 
an execution step for executing the next Activity 
Block (AB) in the course of the selected appli- 
cation session, 20 



wherein in the software program comprises ma- 
chine executable steps for using a communication 
protocol (SCP) connecting said resource manage- 
ment and allocation step, bookkeeping and analysis 25 
step, scheduling and selection step, and the execu- 
tion step to control the execution order and, if nec- 
essary, to transfer information between said re- 
source management and allocation step, book- 
keeping and analysis step, scheduling and selec- 30 
tion step, and execution step. 
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